\section{Introdução}

O \emph{ResultSet} é uma interface que fornece uma abstracção ao paradigma Orientado a Objectos para um conceito do paradigma Relacional: o {\bf cursor}. 
O comportamento e terminologia envolvidos na criação do objecto result set, a sua manipulação, até à sua remoção são os mesmos que se encontram associados a um cursor do servidor (também conhecido como cursor de base de dados).

A implementação da interface \emph{ResultSet} cria um cursor no SQL Server{\footnotemark}, e na sua operação interage com o cursor do servidor de modo a obter ou actualizar os dados do \emph{dataset}{\footnotemark} associado ao cursor.
Este \emph{dataset} corresponde ao conjunto de linhas que satisfazem a condição da \gls{statement} executada usando o método \texttt{executeQuery} da interface \emph{Statement}. A relação entre estas entidades encontra-se representada na Figura \ref{img:rs-cursor}.

\footnotetext[1]{Normalmente é feita uma para excepção para o \emph{ResultSet} do tipo FORWARD\_ONLY/READ\_ONLY em que o \emph{ResultSet} é obtido através da execução de um \gls{batch}.}

\footnotetext[2]{Os termos \emph{dataset} e \emph{result set} são equivalentes quando se referem aos dados seleccionados por uma \gls{statement}. O termo result set também é usado no documento para se referir a uma instância da interface \emph{ResultSet}.}

\begin{figure}[H]
  \caption{Representação da relação entre o \emph{ResultSet}, o cursor servidor e o \emph{dataset}}
  \label{img:rs-cursor}
  \centering
  \includegraphics[width=9.0cm]{images/database/rs-cursor}
\end{figure}

Devido a esta relação \emph{ResultSet}/cursor podemos dizer que criar uma instância do \emph{ResultSet} corresponde a criar um cursor cliente.

\subsection{Problema}

A relação de 1 para 1 entre \emph{ResultSet} e cursor, implica que para cada \emph{ResultSet} criado num programa Java, irá ser alocado e aberto um novo cursor no servidor. 
Como a API JDBC não define um mecanismo que permita tirar partido de um \gls{multithreaded}, para se poder trabalhar concorrentemente sobre um \emph{dataset} é necessário criar um \emph{ResultSet}/cursor para cada entidade concorrente, o que desde logo implica uma maior alocação de recursos. 
A maior alocação de recursos traduz-se em desperdício, porque está claro que vai haver replicação várias vezes da mesma informação. E este é um problema que se verifica tanto no lado do cliente como do servidor. 
Do lado do cliente existe a instanciação de mais objectos.
Do lado do servidor existem mais cursores alocados e abertos.

\subsection{Ideia base da solução}
\label{subsec:main-idea}

As boas práticas do acesso a informação em base de dados ensinam que se deve evitar a utilização de cursores pois normalmente eles utilizam muitos recursos e reduzem o desempenho e a escalabilidade das aplicações \cite{PTUNCURSOR}, e que se devem utilizar alternativas, como por exemplo:
\begin{itemize}
  \item Ciclos \texttt{while}
  \item Tabelas temporárias
  \item Tabelas derivadas
  \item Múltiplas \emph{queries}
\end{itemize}

Uma vez que o modo de operação de um \emph{ResultSet} é linha a linha, temos de continuar a utilizar cursores do servidor. Mas o que se pode fazer é diminuir o número de cursores utilizados. Por isso a ideia base consiste em transformar a relação de 1 para 1 numa relação de muitos para um, isto é, permitir que várias instâncias do \emph{ResultSet} utilizem o mesmo cursor do servidor. Esta alteração é assinalada na Figura \ref{img:rs-cursor-mult}.

\begin{figure}[H]
  \caption{Relação de muitos para um entre o \emph{ResultSet} e o cursor do servidor.}
  \label{img:rs-cursor-mult}
  \centering
  \includegraphics[width=9.0cm]{images/database/rs-cursor-mult}
\end{figure}

A implementação encontra-se, deste modo, preparada para operar num ambiente concorrente, garantindo uma cooperação correcta entre as entidades concorrentes. 
A cada entidade é atribuída uma referência para uma instância do \emph{ResultSet} que por sua vez opera concorrentemente com as outras instâncias sobre o mesmo cursor, permitindo o desejado acesso concorrente ao dataset.

Agora que já se sabe qual é a ideia base da solução, nas duas próximas secções serão descritas duas possíveis soluções concretas; uma implementando a concorrência ao alto nível e outra ao baixo nível.

